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REMARKS/ARGUMENTS 

Claim rejections under 35 U.S.C. 1 12 

Applicants have amended claims 7-8, 20-21, 33-34 to provide proper antecedent basis by 
amending 'the determined storage location' to 'the determined storage location address'. 
Applicants submit that the Examiner has made a typographical error in indicating that antecedent 
basis was lacking in claims 34-35 instead of indicating that antecedent basis was lacking in 
claims 33-34. 

Mistyped commas have also been corrected in claims 9 and 35. 

Claim rejections under 35 U.S.C. 103 

The Examiner has rejected pending claims 1-45. The Examiner rejected claims 1-5, 9-18, 
22-31, 35-45 under 35 U.S.C. 103(a) as being unpatentable over Xu (US 6,324,581) in view of 
Nahum (US 6,898,670). Claims 6-8, 19-21, and 32-34 have been rejected under 35 U.S.C. 
103(a) as being unpatentable over Xu, in view of Nahum, and in view of Porcar ("File Migration 
in Distributed Systems" California Univ., Berkeley, Lawrence, Berkeley Lab, copyright 1982). 
Applicants traverse the rejections of claims 1-45. 

Independent claims 1. 14, and 27 

Independent claims 1, 14, 27 are for controlling and providing access to a files 
maintained at remote storage locations to a source code management system client over a 
network, and require: 

receiving a request, at a server, for checking-out a file corresponding to a filename, from 
the source code management system client over the network; 
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determining from metadata, by the server, a remote storage location address 
associated with the filename where the requested file is located, wherein the metadata includes 
mappings that indicate remote storage location addresses where the files are stored and 
indications of the number of accesses of the files by a plurality of source code management 
system clients, wherein the metadata is stored more proximate to the server than to the source 
code management system client, wherein the remote storage location address is based on a 
history of request patterns from a the plurality of source code management system clients, and 
wherein the history of request patterns includes the indications of the number of accesses of the 
files by the plurality of source code management system clients; 

sending, by the server, the remote storage location address to the source code 
management system client, wherein the remote storage location address where the requested file 
is located is more proximate to the source code management system client than to the server; and 

updating, by the server, the metadata to indicate that the requested file is checked-out and 

locked. 

The Examiner has rejected claims 1 1, 14, and 27 under 35 U.S.C. 103(a) as being 
unpatentable over Xu in view of Nahum. 

Applicants have amended claims 1 1, 14, 27 to include the new requirements that the 
metadata includes mappings that indicate remote storage location addresses where the files are 
stored and indications of the number of accesses of the files by a plurality of source code 
management system clients, and that the history of request patterns includes the indications of 
the number of accesses of the files by the plurality of source code management system clients. 
The added new requirements may be found in at least FIG. 9 and pages 5-13 of the specification, 
and does not add any new matter. 

Nowhere does the cited Xu (col. 10, lines 12-25) or the cited Nahum (fig. 17; col. 9: lines 
31-35; col. 19, line 52 - col. 20, line 18; col. 20: lines 14-18) teach or suggest the claim 
requirements that the metadata includes indications of the number of accesses of the files by a 
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plurality of source code management system clients, and that the history of request patterns 
includes the indications of the number of accesses of the files by the plurality of source code 
management system clients in combination with the other claim requirements. 

The metadata discussed in the cited Xu indicates the storage location where a file is 
stored. The metadata discussed in the cited Nahum is defined by the cited Nahum (Col. 1, lines 
29-30 included under "Definitions") as "the data pertaining to the mapping of the virtual 
volumes." Therefore, neither the cited Xu nor the cited Nahum teach or suggest the claim 
requirement that the metadata includes indications of the number of accesses of the files by a 
plurality of source code management system clients. 

In the office action (page 4) the Examiner has interpreted the claim requirement of the 
history of request patterns as "the location the file has been during previous requests" and has 
mentioned that the history of request patterns is disclosed by col. 10, lines 14-17 of the cited Xu. 
Col. 10, lines 14-17 of the cited Xu discusses that before reading or writing to the file system, a 
client first issues a request for metadata to the data mover, and the data mover responds by 
placing an appropriate lock on the file to be accessed, and returning metadata including pointer to 
where the data to be accessed is stored in the file system. The amended claims require that the 
history of request patterns includes the indications of the number of accesses of the files by the 
plurality of source code management system clients and this claim requirement is nowhere taught 
or suggested by either the cited Xu or the cited Nahum. 

For the above reasons, claims 1, 14, and 27 are patentable over the cited art. 

Independent Claims 10. 23, 36 

Independent claims 10, 23, 36 are for accessing a file in a source code management 

system, comprising: 

sending, from a source code management system client, a first request for checking-out 
the file to a server; 
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receiving, at the source code management system client, a storage location address 
containing the file in response to the first request, wherein the storage location address containing 
the file is located more proximate to the source code management system client than to the 
server, wherein metadata corresponding to the file is kept more proximate to the server than to 
the source code management system client, wherein the storage location has been determined 
from the metadata by the server based on a history of request patterns from a plurality of source 
code management system clients, wherein the metadata includes mappings that indicate storage 
location addresses where files are stored and indications of the number of accesses of the files by 
the plurality of source code management system clients, and wherein the history of request 
patterns includes the indications of the number of accesses of the files by the plurality of source 
code management system clients; 

sending, from the source code management system client, a second request to the storage 

location address; and 

receiving, at the source code management system client, an access to the file from the 
storage location address, wherein the server updates the metadata to indicate that the file is 
checked-out and locked after providing the access. 

The Examiner has rejected claims 10, 23, and 36 under 35 U.S.C. 103(a) as being 
unpatentable over Xu in view of Nahum. 

Applicants have amended claims 10, 23, 36 to include the new requirements that the 
metadata includes mappings that indicate storage location addresses where files are stored and 
indications of the number of accesses of the files by the plurality of source code management 
system clients and that the history of request patterns includes the indications of the number of 
accesses of the files by the plurality of source code management system clients. The added new 
requirements may be found in at least FIG. 9 and pages 5-13 of the specification, and does not 
add any new matter. 
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Nowhere does the cited Xu (col. 10, lines 12-22) or the cited Nahum (fig. 17; col. 9: lines 
31-35; col. 19, line 52 - col. 20, line 18; col. 20: lines 14-18) teach or suggest the claim 
requirements that the metadata includes mappings that indicate storage location addresses where 
files are stored and indications of the number of accesses of the files by the plurality of source 
code management system clients and that the history of request patterns includes the indications 
of the number of accesses of the files by the plurality of source code management system clients 
in combination with the other claim requirements. 

The metadata discussed in the cited Xu indicates the storage location where a file is 
stored. The metadata discussed in the cited Nahum is defined by the cited Nahum (Col. 1, lines 
29-30 included under "Definitions") as "the data pertaining to the mapping of the virtual 
volumes." Therefore, neither the cited Xu nor the cited Nahum teach or suggest the claim 
requirement that the metadata includes indications of the number of accesses of the files by a 
plurality of source code management system clients. 

In the office action (page 10) the Examiner has mentioned that the claim requirement of 
the history of request patterns is disclosed by col. 10, lines 14-19 of the cited Xu. 
Col. 10, lines 14-19 of the cited Xu discusses that before reading or writing to the file system, a 
client first issues a request for metadata to the data mover, and the data mover responds by 
placing an appropriate lock on the file to be accessed, and returning metadata including pointer to 
where the data to be accessed is stored in the file system, and where the client uses the metadata 
to formulate a read or write request sent over the bypass data path to the file system. The 
amended claims require that the history of request patterns includes the indications of the 
number of accesses of the files by the plurality of source code management system clients and 
this requirement is nowhere taught or suggested by either the cited Xu or the cited Nahum. 
For the above reasons, claims 10, 23, and 36 are patentable over the cited art. 
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De pendent claims 2-9. 11-13. 1 5-7.2. 24-26. 28-35. 37-45 

The Examiner has also rejected pending claims 2-9, 11-13, 15-22, 24-26, 28-35, 37-45 
that depend on the pending independent claims 1, 14, 27, 10, 23, or 36. Applicants submit that 
these claims are patentable over the cited art because they depend from claims 1, 14, 27, 10, 23, 
or 36 which are patentable over the cited art for the reason discussed above, and because the 
combination of the limitations in the dependent claims 2-9, 11-13, 15-22, 24-26, 28-35, 37-45 
and the base and intervening claims from which they depend provide further grounds of 
distinction over the cited art. 



Claims 4. 17. 30 

Claims 4, 17, 20 depend on claims 3, 16, 29 respectively, further comprising: 
locking the requested file; 

returning a response code to the source code management system client indicating that 

file check-out is successful. 

The Examiner has rejected claims 4, 17, 30 under 35 U.S.C. 103(a) as being unpatentable 

over Xu in view of Nahum. 

Nowhere does the Examiner cited Xu (col. 9, lines 59 - col. 10, lines 25) [or the cited 
Nahum] teach or suggest the claim requirements of returning a response code to the source code 
management system client indicating that file check-out is successful. 

The cited Xu discusses that the data mover responds by placing an appropriate lock on the 
file to be accessed and returning metadata to the client. Should the Examiner maintain the 
rejection the Examiner is requested to indicated where the cited Xu (or the cited Nahum) teach or 
suggest the claim requirements returning a response code to the source code management system 
client indicating that file check-out is successful . 

For the above reasons claims 4, 17, 30 are patentable over the cited art. 
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Claims 5. 18.31 

Claims 5, 18, 31 depend on claims 4, 17, 30 respectively, wherein the request is a first 
request, wherein the file for checking-out is a first file, wherein the response code is a first 
response code, and wherein a second request is for checking-in a second file, the method further 
comprising: 

updating the metadata indicating the requested second file is unlocked; and 
returning a second response code indicating that the check-in of the second file is 
successful. 

Nowhere does the Examiner cited Xu (col. 10, lines 17-25) [or the cited Nahum] teach or 
suggest the following claim requirements: 

(a) updating the metadata indicating the requested second file is unlocked; 

(b) returning a second response code indicating that the check-in of the second file is 
successful. 

The Examiner cited col. 10, lines 17-25 of the cited Xu discusses placing appropriated 
locks on the file to be accessed, and returning metadata including pointers to where the data to be 
accessed is stored in the file system. The client may write the new file attributes to the data 
mover after the data is written to the file system. 

Should the Examiner maintain the rejection of the claims, the Examiner is requested to 
indicated where the cited Xu (or the cited Nahum) teach or suggest the claim requirements of: 

(a) updating the metadata indicating the requested second file is unlocked; 

(b) returning a second response code indicating that the check-in of the second file is 
successful. 

For the above reasons claims 5, 1 8, 3 1 are patentable over the cited art. 
Claims 13. 26. 39 

Claims 13, 26, 39 depend on claim 10, 23, 36 respectively and further require: 
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receiving a first response code from the server in response to the first request; 
receiving a second response code from the storage location in response to the second 
request; and 

receiving a third response code from the server in response to the third request. 

The cited Xu (col. 10, lines 14-19) discusses locking, returning metadata, writing new file 
attributes, etc. Nowhere does the cited Xu teach or suggest the claim requirement of receiving a 
first response code from the server in response to the first request; receiving a second response 
code from the storage location in response to the second request; and receiving a third response 
code from the server in response to the third request. 

Should the Examiner maintain the rejection of the claims the Examiner is requested to 
indicate which element of the cited Xu corresponds to: 

(a) a first response code 

(b) a first request 

(c) a second response code 

(d) a second request 

(e) a third response code 

(f) a third request. 

For the above reasons claims 13, 26, 39 are patentable over the cited art. 

Amended claims 40-45 

Amended claims 40-45 included the newly added requirements that wherein the 
indications of the number of accesses of the files by the plurality of source code management 
system clients included in the metadata indicates that the first source code management system 
client has accessed the file a greater number of times than the second source code management 
system client. The newly added requirements may be found in at least FIGs. 9 and 10, and pages 
12-13 of the specification. 
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Nowhere does the cited Xu or the cited Nahum teach or suggest the newly added claim 
requirements that the indications of the number of accesses of the files by the plurality of source 
code management system clients included in the metadata indicates that the first source code 
management system client has accessed the file a greater number of times than the second source 
code management system client. 

For the above reasons claims 40-45 are patentable over the cited art. 



Claims 6. 19. 32 

Claims 6, 19, 32 depend on claims 1, 14, 27 respectively, wherein a table maintains 
statistics for file usage, and further comprises: 

processing a pattern of requests for the requested file received from source code 
management system clients at different geographical locations; 

determining from the table a plurality of remote storage locations based on the pattern of 

requests for the requested file; 

storing the requested file corresponding to the filename at the determined plurality of 

remote storage locations; and 

saving a correspondence between the requested file and storage location addresses 
corresponding to the determined plurality of remote storage locations in the metadata. 

The Examiner has rejected claims 6, 19, 32 as being unpatentable under 35 U.S.C. 103(a) 
as being unpatentable over Xu in view of Nahum and in view of Porcar. Applicants traverse. 

The claims require: 

(a) a table that maintains statistics for file usage, 

(b) determining from the table a plurality of remote storage locations based on the pattern of 
requests for the requested file; 

(c) storing the requested file corresponding to the filename at the determined plurality of remote 
storage locations; 
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The cited Porcar discusses file migration in distributed computer systems that maintain 
multiple copies of files. Files are moved around in a distributed computer system based on 
certain policies in response to the referencing of files, such as updates of files. 
The Examiner has mentioned (Office action page 14) that the migration policies discussed in 
section 5.2 of the cited Porcar discloses the claim requirements of a table that maintains statistics 
for file usage and determining from the table a plurality of remote storage locations based on the 
pattern of requests for the requested file. Applicants submit that nowhere does the cited Porcar 
teach or suggest the claim requirement of a table. Since the cited Porcar does not suggest the 
claim requirement of a table, the cited Porcar does not teach or suggest the claim requirements of 
a table that maintains statistics for file usage, and determining from the table a plurality of remote 
storage locations based on the pattern of requests for the requested file. 

Furthermore, the claims require determining from the table a plurality of remote storage 
locations based on the pattern of requests for the requested file and storing the requested file 
corresponding to the filename at the determined plurality of remote storage locations. The cited 
Porcar teaches away from the claim requirements because the cited Porcar maintains the master 
copy as local to the user updating the file (cited Porcar: page 121, line 19 included the third 

paragraph of page 121 that starts with "As we described in section 5.1.1 " ). In page 1 17 it is 

indicated in the cited Porcar in 5. 1 . 1 . that "for each file, there is at least one copy, the master 

copy, in the system at all times In our implementation, the master copy is never deleted". As 

described above the master copy is local to the user updating the file, i.e., the master copy is local 
to the remote computer. Therefore, the master copy and the distribution of the master copy 
teaches away from the claim requirements of determining from the table a plurality of remote 
storage locations based on the pattern of requests for the requested file and storing the requested 
file corresponding to the filename at the determined plurality of remote storage locations. 

Additionally, the motivation of the cited Porcar of reducing the traffic an order of 
magnitude as compared to single copy policies (Porcar 5.4 conclusions) used by the Examiner to 
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modify the system of the cited Xu with the teachings of the cited Porcar is improper. The 
reduction of traffic in the cited Porcar is caused by the removal of "copies that exceed a retention 
cost based on storage costs and update traffic costs" (cited Porcar, page 134). Therefore, the cited 
Porcar is motivating reduction of traffic by removing copies of files. If copies of files are 
removed in the system of the cited Xu then when requests are made to the data movers of the 
cited Xu the requests from the client cannot not be satisfied and the system of the cited Xu would 
be inoperable. Therefore, modifying the system of the cited Xu according to the motivation 
provided by the cited Porcar is improper as it would lead to an inoperable system in the cited Xu. 
For the above reasons, claims 6, 19, and 32 are patentable over the cited art. 



Claims 7. 20. 33 

Claims 7, 20, 33 depend on claims 6, 19, 32 respectively, wherein , wherein the 
determined remote storage location address is at a geographical location that is more proximate 
to the source code management system client having more requests for the requested file than 
other source code management system clients. 

The cited Porcar (section 5.1.6 distributing the updates) used in rejecting the claim 
requirements discusses that when a master copy has been updated, the remaining copies are 
brought up to date by transmitting all updates in a batch. Reads to local copies are made 
inexpensive. Files are synchronized. A weighted voting mechanism and file version numbers are 
used to decide what are the files that contain current information. Nowhere does the cited Porcar 
teach or suggest the claim requirement that the one determined remote storage location is at a 
geographical location that is more proximate to the source code management system client 
having more requests for the requested file than other source code management system clients. 
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Additionally, there is no motivation provided by the Examiner to combine the teachings 
or suggestions of the cited Porcar, the cited Xu and the cited Nahum to arrive at the claim 
requirements of claims 7, 20, 33. 

For the above reasons claims 7, 20, 33 are patentable over the cited art. 



Claims 8.21,34 

Claims 8, 20, 33 depend on claims 6, 19, 32 respectively, wherein the determined remote 
storage location address is selected from the plurality of remote storage locations to minimize a 
distance the requested file is transmitted between each source code management system client 
and the determined remote storage location based on the number of requests for the file from 
each source code management system client. 

The cited Porcar (section 5.2 Migration policies) used in rejecting the claim requirements 
discusses migration policies for files in a distributed system based on an extension of the space 
time working set policy (Porcar: page 123) The space time working set policy removes any copy 
based on fetching costs to storage costs, and a ratio of update communications to storage costs. 
Nowhere does the cited Porcar teach or suggest the claim requirement that the determined remote 
storage location address is selected from the plurality of remote storage locations to minimize a 
distance the requested file is transmitted between each source code management system client 
and the determined remote storage location based on the number of requests for the file from 
each source code management system client. 

Additionally, there is no motivation provided by the Examiner to combine the teachings 
or suggestions of the cited Porcar, with the cited Xu and the cited Nahum to arrive at the claim 
requirements of claims 8, 20, 33. 

For the above reasons claims 8, 21, 34 are patentable over the cited art. 

Conclusion 

For all the above reasons, Applicant submits that the pending claims are patentable over 
the art of record. Applicants have indicated appropriate fees. Nonetheless, should any additional 
fees be required, please charge Deposit Account No. 09-0449. 
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The attorney/agent invites the Examiner to contact him at (310) 557-2292 
Examiner believes such contact would advance the prosecution of the case. 



Please direct all correspondences to : 

Rabindranath Dutta 

Konrad Raynes & Victor, LLP 

315 South Beverly Drive, Ste. 210 

Beverly Hills, CA 90212 

Tel: 310-557-2292 

Fax:310-556-7984 



Dated: January 23. 2006 




Rabindranath Dutta 
Registration No. 5 1 ,0 1 0 
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